[小ネタ]Lambdaのトリガーと送信先で障害時の送信先を同じSNSに設定した場合の挙動を確認する

はじめに

CX事業本部東京オフィスの佐藤智樹です。

今回はLambdaのトリガーと送信先で障害時の送信先を同じSNSに設定した場合の挙動を確認します。少し前のアップデートでLambdaのストリーミング呼び出しの際のエラーハンドリングが追加されました。

ただLambdaの送信先の設定にも同じようにストリーム呼び出しで障害時の送信先が設定できます。そこでトリガーと送信先に同じSNSトピックを設定した場合どうなるのか検証しました。

要約

トリガーと送信先で障害時の送信先を同じSNSトピックを設定しても通知は1回だけ行われる。

事前準備

DynamoDB StreamsからLambdaを起動し、SNSへトピックを送るためのLambdaを設定します。Lambdaはトリガーからの再試行回数を1回に指定して、エラーが1回発生した場合にSNSトピックから何回メール通知されるのか確認します。

Lambdaを作成

適当な名前でLambdaを作成します。今回は「DynamoDbStreamSample」で作成し、適当にエラーを発生させるためコードの一部の括弧を削除します。

DynamoDBのテーブルを作成

次にストリーム呼び出しを行うためにDynamoDBのテーブルを作成します。今回はテーブル名を「LambdaDestinationsSample」としています。テーブル作成後にLambdaへ送るためのストリームを作成します。ストリームさえ送れれば良いので設定はどれでも良いですが、今回は新旧イメージを送信することにします。

SNSトピックを作成

SNSトピックを作成します。トピック作成後、サブスクライブ先をEmailに設定します。メールの受信数で実行回数を確認します。

ロールの設定

DynamoDB StreamsからLambdaを実行できるポリシーとSNSへ送信するポリシーをアタッチしたロールを作成します。具体的には以下のデフォルトで存在するポリシーをアタッチしたロールを作成します。

• AWSLambdaDynamoDBExecutionRole
• AmazonSNSFullAccess

Lambdaにロールをアタッチ

上記の準備ができたらLambdaにロールをアタッチします。WebコンソールでLambdaを開いて、「アクセス権限」タブで先ほど作成したロールをアタッチします。

Lambdaにストリーム呼び出しのトリガーを設定

DynamoDBからLambdaを呼び出すためトリガーを設定します。Lambdaのコンソールから「トリガー」を選択して、トリガーに「DynamoDB」、DynamoDBテーブルに先ほど作成したテーブルのArnを設定します。

次に障害時の送信先に作成したSNSトピックののArnを設定し、再試行を「1」に設定します。他の設定は今回の検証に関係ないですが画面の通り設定してください。終わったら追加ボタンを押下します。問題がなければ正常にトリガーが追加されます。

送信先の設定

最後に送信先を設定します。送信先を押下してソースでストリーム呼び出しを選択し、ストリームは作成したDynamoDBのストリームを選択します。Conditionはon Failureで送信先タイプを作成したSNSトピックに設定します。これで準備完了です。

最終的には以下の画面のようになります。

動作確認

作業の準備ができたので、DynamoDBテーブルに値を追加してLambdaをストリームから実行します。

CloudWatchLogsを見ると初回実行時と再試行時の2回実行されていることが確認できます。

SNSのサブスクライブ先のメールアドレスを確認するとメールが1通だけ届いていることが確認できました。

したがって、トリガーと送信先で同じSNSトピックに送信先を設定しても1度しかデータは送られないようです。間違ってトリガーと送信先に同じ設定をしたとしても問題無さそうです。後ついでにトリガーからSNSトピックへの通知を消した場合でも、送信先の設定でSNSへの通知は行われていました。

雑感

あまり役に立つ内容では無いですが同じような設定を2重に設定したらどうなるのか気になったので検証しました。間違って設定しない限りあまり無いパターンだと思いますが参考になれば幸いです。